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0.  Executive  Summary 

The  application  of  computational  techniques  to  manufacturing  and  to  the 
management  of  manufacturing  enterprises  is  both  broad  and  diverse.  The  effectiveness  of 
automating  physical  manufacturing  processes  sparked  optimism  that  automating  the  less 
tangible  management  processes  such  as  planning,  scheduling  and  control  could  also  be 
effective.  The  hope  was  and  is  to  use  computational  techniques  to  reduce  the  cost  of 
managing  complex  activities  and  to  increase  responsiveness  to  both  scheduled  and  non- 
scheduled  events.  This  latter  type  of  automation,  though,  has  proven  much  mcve  difficult 
since  it  deals  with  the  complexities  of  human  mental  activity  as  opposed  to  the  operation 
of  physical  machines.  Part  of  the  difticulty  relates  to  the  computer  languages  which  are 
used  to  represent  management  situations  as  well  as  the  inferences  which  must  be  made 
regarding  those  situations.  Formal  lo^cs  of  different  kinds  are  usually  the  basis  for 
computer  languages  which  can  handle  inference.  However,  noost  of  these  languages  deal 
with  v^  constrained  types  of  inference  which  are  inadequate  to  represent  die  breadth  of 
reasrming  needed  to  automate  decisions  found  in  manufacturing  envircmments.  The  goal 
of  this  Phase  n  SBIR  has  been  to  develop  a  computer  language.  Logistics,  for  building 
reasoning  systems  capable  of  modeling  more  complex  situations  than  is  currently  the 
case. 

Logistics  is  a  computer  language  which  is  used  as  a  tool  for  building  inference 
systems.  It  is  not  based  on  a  particular  kind  of  logic,  but  allows  different  kin^  of  logics 
to  be  defined  and  used  as  the  basis  for  reasoning  systems.  The  value  of  this  fact  is  that  the 
lan^age  is  v^  flexible  and  may  be  applied  to  many  different  situations.  Currently, 
Logistics  is  being  tqiplied  in  two  very  diverse  contexts.  First,  Logistics  is  being  used  as 
part  of  Ontek  Corporation’s  work  on  PACIS  (a  Platform  for  the  Automated  Construction 
of  Intelligent  Systems).  That  work  is  being  carried  out  under  the  Air  Force  Manufacturing 
Technology  (ManTech)  Directorate's  Integrated  Toolkit  and  Methods  contract.  Corporate 
Data  Intention  Tools  project  (FTKM  CDIT).  Logistics  is  also  deployed  into  a 
manufacturing  system  being  developed  by  Allied  Signd  Aerospace  at  the  Department  of 
Energy's  Kansas  City  plant.  In  that  project.  Logistics  is  being  used  as  a  tool  for  reasoning 
about  manufacturing  actions,  feature  constraints  on  product  designs,  and  as  a  tool  for 
translating  product  descriptions  between  different  product  description  languages.  Both 
these  applications  provide  real  world  problems  which  test  Logistica's  inference 
capabilities.  Also,  each  of  the  application  projects  are  deriving  real  benefit  from 
Logistics.  In  the  case  of  PACIS,  one  the  fundamental  technical  requirements  supporting 
Kveral  higher  level  requirements  is  met  by  Logistics.  The  PACIS  project  intends  to 
iiKOtporate  Logistics  constructs  and  formalisms  into  its  system  platform.  At  Allied 
Signal  Logistica  was  originally  purchased  to  build  reasoning  systems  that  would  facilitate 
understanding  and  representing  the  results  of  mechanic^  manufacturing  actions  and 
men^  actions  involved  in  the  design  process.  Allied  Signal  subsequently  discovered  that 
Logistica  was  also  a  very  useful  language  for  implennenting  translation  processes,  and  for 
verifying  design  constraints  and  consistency.  In  fact,  they  have  found  Logistica  to  be  so 
useful  that  one  development  ^up  is  considering  rewriting  substantial  parts  of  their 
existing  manufacturing  system  in  the  Logistica  language. 

This  Phase  n  SBIR  represents  advanced  theoretical  work  in  computational,  logic- 
based  inference,  which  combined  with  the  two  implementations  mentioned  above, 
expand  Logistica's  scope  beyond  academic  interest  to  include  solutions  to  previously 
intractable  teal- world  manufacturing  problems. 

1.  Introduction 

The  overall,  long-term  objective  of  the  work  described  in  this  technical  report  is 
to  develop  and  implement  a  general,  self-extensible,  knowledge-based  reasoning 
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technology  specifically  targeted  for  use  in  comprehensive  manufacturing  and 
management  operations  systems.  This  technology  provides  manufacturing  and 
management  operations  systems  with  an  automated  reasoning  mechanism  for  inrarring 
the  potential  cmisequence  of  actions,  and  for  planning  s^uences  of  manufacturing  and 
management  operations  to  achieve  specific  organizational  goals.  This  technology 
substantially  increases  the  reasoning  ability  of  current  manufacturing  and  management 
operations  systems,  thus  allowing  Ae  simpler  decisitm-making  tasks  to  be  automated, 
liiis,  in  turn,  leads  to  deoeases  in  overall  indirect  costs  to  design  and  manufacturing 
products. 

The  specific  objective  of  this  SBIR  Phase  n  project  was  to  develop  multiple 
automated  (Auction  systems  based  on  a  general  knowledge-based  reascHiing  technology 
and  suitable  for  use  in  large  management  and  manufacniring  systems.  The  motivations 
for  this  project  are  descri^  in  Section  2.  of  this  repo^  The  objectives  of  the  project 
were  carried  out  b^  first  develc^ing  a  general  reasoning  tool  called  Logistica  which 
allows  a  user  to  easily  implement  sophisticated  deductive  reasoning  systems,  and  then  by 
implementing  specific  rule  systems  in  Logistica  dealing  with  management  and 
manufacturing  problems.  Logistica  is  a  unique  very-high-level  (VHL)  reasoning  tool 
based  on  pattern-directed  invocation,  multiple  execution  threads  and  user-definable 
ccmtrol  structures.  It  is  described  in  Section  3.  of  this  report  Our  approach  to  developing 
complex  reasoning  system  by  abstracting  out  commonly  used  features  and  embedding 
them  into  the  Logistica  language  is  discussed  in  Section  4.,  along  with  some  of  the 
lessons  which  were  learned  during  the  development  and  use  of  this  system. 

During  the  course  of  this  proj^t,  Logistica  was  applied  and  used  by  two 
conmanies.  Rrst  it  was  used  as  part  of  Ont^  Corporation's  wo^  on  PACIS  (a  Platform 
for  me  Automated  Construction  of  Intelligent  Systems).  That  wmk  is  being  carried  out 
under  the  Air  Fmce  Manufacturing  Technology  (ManTech)  Directorate's  Integrated 
Toolkit  and  Methods  contract,  CorpOTate  Data  mteg^tion  Tools  projea  (ITKM  C^IT). 
In  that  project,  the  Logutica  technolo^  is  providing  a  key  underlying  capability  — 
pattera-dirMted  invocation  —  which  is  being  used  to  help  meet  several  important 
technical  requirements.  Logistica  was  also  deployed  into  a  manufacturing  system  being 
develtqied  by  Allied  Signal  Aerospace  at  the  Dq)artment  of  Energy’s  Kansas  City  plant 
In  that  project  Logistica  was  used  as  a  tool  fct  reasoning  about  manufacturing  actions, 
feature  constraints  on  project  designs,  and  as  a  tool  for  translating  produa  descriptions 
between  different  prod^  description  languages.  This  deployment  took  the  form  of  a  sale 
to  Allied  Signal  Aerospace  of  Logistica  software,  as  well  as  a  set  of  Logistica  rules  which 
implement  nonmonotonic  reasoning.  These  applications  and  deployments  of  Logistica 
technology  are  discussed  in  Section  5.  of  tins  report.  Hnally,  some  conclusions  are 
discussed  in  Section  6. 

2.  Project  Motivations 

A  ^at  deal  of  effort  is  currently  being  expended  on  developing  large 
manufacturing  and  management  control  systems  in  order  to  improve  productivity  in  the 
industrial  base.  Hiese  efforts  are  intended  to  model  many  aspects  of  the  design  and 
manufacture  of  products,  including  me  representation  of  those  processes,  and  the  use  of 
the  representation  for  management  of  those  processes.  While  the  representation  of  such 
knowledge,  as  well  as  the  storage  and  retrieval  of  such  knowledge,  are  mernselves 
significant  achievements,  such  systems  would  be  significantly  enhan^  by  me  ability  to 
automatically  determine  me  important  consequences  which  might  follow  ^m  analyzing 
data  report^  to  me  system  in  me  context  of  me  base  knowledge  represented  in  me 
system.  One  very  important  class  of  consequences  which  we  would  like  to  be  able  to 
detomine,  are  mose  which  follow  when  an  action  or  event  occurs.  For  example,  when  me 
manufacturing  system  is  told  that  a  red-colored  woiit-in-process  part  was  moved  from 


one  shop  flo(Mr  location  to  another,  it  probably  should  infer  that  the  part  is  at  the  new 
location.  For  obvious  consequences,  this  is  accomplished  by  storing  a  rule  or  law 
describing  what  happens  when  something  is  moved.  Unfortunately,  many  actions,  such  as 
those  in  a  complex  environment  like  a  manufacturing  enterprise,  generally  have  many 
unobvious  consixiuences.  For  example,  if  a  red  light  htd  been  shining  at  the  first  location, 
but  a  green  light  were  shining  at  the  new  location,  the  property  that  the  pan  appears  red- 
coloft^  might  also  have  changed  as  a  result  of  the  move.  For  this  reason  we  cannot,  as  is 
often  dmie  in  current  planning  systems,  just  make  an  assumption  that  everything  except 
the  obvious  results  remain  the  same.  We  need  to  be  more  precise,  i.e.,  we  need  to  need  to 
be  able  to  say  stnnething  like  'everything  remains  the  same  unless  it  contradicts  the  direct 
results  of  the  action  or  cenain  qualitative  physical  laws  (such  as  an  object  may  only 
reflect  the  color  of  those  sources  of  light  for  which  there  is  such  a  source  at  the  given 
location)".  This  problem,  of  specifically  describing  what  does  and  does  not  change  is 
known  as  the  'Frame  Problem'  in  artificial  intelligence,  and  is  the  subject  of  a  growing 
body  of  research  [Brown87;  Ford  &  F^yes90].  Theories  and  logics  for  d^ucing  such 
unobvious  consequences  are  generally  called  nonmonotonic  reasoning  systems. 

The  basic  scientific  problem  addressed  under  this  SBIR  was,  therefore,  to  predict 
the  unobvious  consequences  of  actions  involving  manufacturing  operations  and  their 
management.  Our  opportunity  to  significantly  address  this  problem  lies  in  the  fact  that  we 
have  developed  a  scientiHc  theory  of  such  nonmonotonic  reasoning  mechanisms  that 
explains  the  reasoning  carried  out  in  almost  gU  of  these  kinds  of  problems.  The  theory  has 
been  shown  to  encompass  and  generalize  almost  all  other  competing  theories  of  such 
reasoning  in  the  literature  [Brown86a,b,c,d,87,90;  Brown  &  Park87,88].  Thus,  in  order  to 
actually  build  computer  programs  which  carry  out  such  reasoning,  there  was  a  need  to 
find  a  way  to  develop  a  technology  which  would  allow  a  user  to  quickly  implement 
sophisticated  reasoning  process.  This  would  entail  experimentally  developing  a  computer 
model  of  the  reasoning  process,  based  on  our  scientific  theory  of  such  reasoning.  In  the 
course  of  this  project  we  developed  just  such  an  implementation  technology,  which  we 
call  Lx>gistica.  Logistica  also  draws  on  our  previous  research  on  automatic  deduction 
systems.  Logistica  was  then  used  to  develop  a  comprehensive  rule  system  for 
ncmmonotonic  reasoning  about  actions,  called  NONMON.  The  Logistica  system  and 
NONMON  are  described  in  Section  3. 

3.  Logistica:  an  Expert  System  for  Building  Expert 
Systems 

Logistica  is  a  lexically-scoped  functional  programming  language  used  for 
implementing  deductive  reasoning  processes.  Although  at  the  simplest  level  Logistica 
looks  like  the  Scheme  dialect  [AbelsonSS;  Rees86]  of  LISP  [McCarthytiO;  Church4I;  and 
Steele90]  it  differs  in  that  symbols  may  have  any  number  of  deHnitions  instead  of  always 
just  one  as  in  Scheme.  The  reason  for  this  difference  is  that  there  are  usually  many 
axiomatic  properties  of  any  symbol  and  thus  to  represent  them  in  a  useful  modular 
fashion  a  separate  definition  is  needed  to  represent  each  property.  For  example,  one 
definition  of  conjunction  might  represent  the  associative  law  of  conjunction,  and  another 
definition  might  represent  the  idempotent  law  of  conjunction.  In  the  simple  case  where  no 
symbol  is  defined  more  than  once,  Logistica  is  essentially  Scheme.  For  this  reason, 
Logistica  can  be  viewed  as  one  possible  explication  of  the  thesis  that  deduction  and 
computation  are  similar  activities  [Hayes73;  Kowalski79].  Allowing  multiple  definitions 
of  S}^lx>ls  is  reminiscent  of  Prolog's  [Colmerauer73;  Kowalski74]  use  of  several  clauses 
begmi^g  with  a  particular  predicate  to  axiomatize  that  predicate.  The  difference  is  that 
Logistica  allows  multiple  definitions  of  all  its  symbols,  including  predicates,  functions, 
a^  logical  connectives.  The  consequence  of  this  rather  slight  conceptual  change  is  quite 
significant,  in  that  expressions  may  have  multiple  values.  Control  facilities  similar  to  the 
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cut  operation  of  Prolog  are  included  for  dealing  with  multiple  values.  Because  Logistica 
enables  the  specification  of  arbitrary  deductive  systems  (by  representing  the  properties  of 
symbols  as  'l^ktrackable  rewrite  rules'  which  are  associated  to  the  symbols  themselves), 
it  is  independent  of  any  specific  logic  and  it  provides  instead  the  basic  tools  for  deduction 
[Araya90a  and  90b;  Brown86a,  86b,  87, 89, 91a,  91b,  and  92;  Hundal91;  and  Park88]. 

A  second  important  way  in  which  Logistica  differs  from  the  Scheme  dialect  of 
LISP  is  that  it  allows  symbolic  expressions  to  be  the  results  of  evaluation.  The  reason  for 
Ais  difference  is  that  symbolic  expressions  involving  variables,  such  as  those  occurring 
in  the  scope  of  an  existential  or  universal  quantifier,  generally  do  not  evaluate  to  specific 
values,  but  are  essentially  place  holders  which  may  be  manipulated  by  logical  inference 
operations. 

These  differences  while  allowing  new  and  powerful  programming  metaphors  in 
themselves,  are  integrated  with  the  language  Scheme,  a  popular  LISP  dialect.  This 
integration  gives  the  programmer  a  seamless  and  natural  progression  of  tools,  from  the 
s^ghtforward  functional  programming  approach  of  Schente  or  LISP  to  the  powerful  and 
highly  descriptive  expression  of  alternative  symbolic  computations  afforded  by  Logistica. 
These  two  major  differences  from  LISP  are  discussed  in  more  detail  below,  in  sections 
3.1  and  3.2,  respectively.  Some  example  programs  exhibiting  the  utility  of  these 
^ditional  capabilities  found  in  Logistica  are  also  described.  Section  3.3  rounds  out  this 
introduction  to  Logistica  with  a  brief  presentation  of  its  other  important  features. 

3.1  The  Multi-Valued  Nature  of  Logistica 

The  first  difference  is  that  symbols  may  have  any  number  of  definitions  instead  of 
always  just  one  as  in  Scheme.  The  reason  for  this  difference  is  that  there  are  usually  many 
axiomatic  properties  of  any  symbol  and  thus  to  represent  them  in  a  useful  modular 
fashion  a  separate  definition  is  needed  to  represent  each  property.  For  example,  one 
defnition  of  conjunction  might  represent  the  associative  law  of  conjunction,  and  another 
definition  might  represent  the  idempotent  law  of  conjunction.  In  the  simple  case  where  no 
symbol  is  defined  more  than  once,  Logistica  is  essentially  the  same  as  Scheme.  For  this 
reason,  Logistica  can  be  viewed  as  one  possible  explication  of  the  thesis  that  deduction 
and  computation  are  similar  activities.  Allowing  multiple  definitions  of  symbols  is 
reminiscent  of  Prolog's  use  of  several  clauses  beginning  with  a  particular  pi^icate  to 
axiomatize  that  predicate.  The  difference  is  that  Logistica  allows  multiple  definitions  of 
all  its  symbols,  including  predicates,  functions,  and  logical  connectives.  Logistica  allows 
not  only  single-valued  expressions,  but  also  multi-valued  and  no-valued  expressions. 
Single-valued  expressions  evaluate  to  a  single  value.  For  example: 

<*  5  8)  =>  40 

No-valued  expressions  evaluate  to  no  values.  Such  a  result  is  indicated  in  the  meta 
language  as  failure.  For  example: 

«£aii  =>  failure 

Multi-valued  expressions  are  created  by  defining  additional  values.  They  evaluate  to 
more  than  one  v^ue.  For  example: 

(l«t((z  1)) (dafin*  X  2) (deflna  x  3)x} 


=>  3 
=>  2 
=>  1 


Multiple  definitions  are  specified  in  a  combination  of  two  ways,  either  by  using  multiple 
define  statements  (as  shown  above)  or  by  pattern  matching,  in  more  than  one  way,  the 
formals  of  a  closure  being  applied,  as  shown  below: 

(l«t((<llst  ...a  z  ..33)  '(1  2  3))3c)  =>  1 

=>  2 
=»  3 

In  this  last  example, . .  .a  and  . .  .b  are  segment  variables  which  match  zero  or  more 
expressions  in  the  argument  ‘(1  2  3),  or  rather  the  list,  (list  1  2  3).  Once  multiple  values 
are  produced,  computation  may  proceed  on  the  individual  values  in  a  generic  manner  by 
merely  applying  o^rations  to  ^e  entire  expression; 

(•(■  10  (lat  ( ( (list  ...a  X  ..Jb)  •(!  2  3))z))  =»  11 

=»  12 
=>  13 

The  different  values  may  then  be  joined  together  as  a  single  value: 

(stz«aa->llat 

(joln(-f  10(lat(((liat  ...a  x  ..Jb)  '(1  2  3))x))))  =>  ’(11  12  13) 

The  join  special  form  returns  a  stream  of  all  the  values  of  its  argument  expression.  The 
procedure  stream->list  creates  a  list  of  the  values  from  that  stream.  The  operations  of 
generating  multiple  values,  applying  operations  to  multiple  values,  and  then  joining  those 
results  together  over  and  over  again  is  an  enduring  metaphor  in  Logistica  programming. 

Here  is  a  simple  example  program  using  multiple  values  to  solve  the  'eight 
queens'  puzzle.  The  eight  queens  puzzle  asks  how  to  place  eight  queens  on  a  chessboard 
so  that  no  queen  may  be  captured  by  any  other  queen,  i.e.,  where  no  two  queens  are  on 
the  same  row,  column,  or  diagonal.  One  way  to  solve  this  problem  is  to  work  down  the 
board,  row  by  row,  placing  a  queen  in  some  column  position  in  each  row  such  that  no 
previous  queen  has  l^n  placed  in  that  same  colunm  and  or  along  any  diagonal  from  that 
position.  We  think  of  the  queens'  positions  on  a  chessboard  as  being  represented  by  a  list 
of  numbers  where  the  last  number  represents  the  column  position  of  the  queen  placed  on 
the  last  row,  and  the  second  to  last  number  represents  the  column  position  of  the  queen 
placed  on  the  second  to  last  row,  and  so  forth.  Thus  '(4  2736851)  represents  the 
placement  of  8  queens  with  the  row  1  queen  in  colunm  4,  the  row  2  queen  in  column  2, 
the  row  3  queen  in  column  7,  and  so  forth.  Likewise  '  (8  5  i)  represents  the  partial 
solution  of  placing  the  row  6  queen  in  column  8,  the  row  7  queen  in  colunm  5  and  the 
row  8  queen  in  column  1.  Using  this  representation,  the  following  program  solves  this 
puzzle: 

(defln*  (quMn8(ll8t  ...s  col  ...t) 

(land  b(!not(list:  ~.p 

(!test  c  (»(■(■  (length (ll8t  ...p))l) 

(ab8(-  col  c))))...q)))) 
(queen8(llst  ...s  ...t)  (con8  col  b) ) ) 

(define! (qaeene  ' (}b)  b) 

The  first  definition  of  queens  takes  the  list  of  remaining  column  positions,  and  a 
partial  solution  consisting  of  a  list  of  column  positions  of  queens  already  placed  on  the 
latter  rows  of  the  board.  This  procedure  checks  —  for  each  column  in  the  list  of  columns 
—  whether  some  queen  already  placed  on  the  board  can  capture  a  queen  at  that  position 
through  some  diagonal.  If  so,  it  fails,  but  if  not,  the  procedure  recursively  calls  itself.  The 
call  is  made  using  the  list  of  columns  with  the  currently  chosen  colunm  eliminated  and 


the  new  solution  board  consisting  of  adding  the  newly  chosen  column  position  to  the  next 
early  row  position  of  the  old  partial  solution.  The  second  deHnition  of  queens  simply 
returns  the  resulting  solution  when  all  the  queens  have  been  placed. 


Calling  the  queens  procedure  with  the  initial  list  of  columns  and  an  empty  initial 
board  pixxluces  92  solutions,  of  which  the  tirst  few  are  shown  below; 


(esammns  '  (1  2  3  4  5  6  7  8)  '  () ) ) 
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and 

so  . 

forth 

If  only  one  solution  is  desired  we  call; 


(hAad(joln(quMns  '  (1  2  3  4  5  6  7  8)  •()))) ) 

=»  '(4  273885  1) 


3.2  The  Symbolic  Nature  of  Logistica 

The  second  difference  is  that  when  Logistica  evaluates  an  expression  it  returns  the 
normal  form  of  that  expression  rather  than  the  meaning  of  that  expression.  The  reason  for 
this  difference  is  that  Logistica  always  has  a  representation  for  its  expressions  and  their 
normal  forms,  whereas  it  may  not  have  a  representation  of  the  meanings  of  expressions  if 
those  meanings  refer  to  things  outside  of  Logistica.  For  example,  the  expression  n  refers 
to  a  real  number  which  is  not  itself  an  expression  of  Logistica,  just  as  the  expression 
Colonel'William'Barret'  Travis  refers  to  the  commander  of  the  Alamo  who  is  not  himself 
an  expression  in  Logistica.  Thus,  unlike  traditional  programming  languages  such  as 
Scheme  whose  expressions  are  restricted  to  those  expressions  whose  meanings  are 
themselves  expressions  in  some  datum  language,  Logistica  makes  no  such  restrictions 
whatsoever.  In  the  simple  case,  where  the  expression  being  evaluated  is  the  name  of  an 
expression  in  some  datum  language,  Logistica  operates  just  like  Scheme,  except  that  the 
final  output  is  quoted.  The  symbolic  nature  of  Logistica  is  well  exempliHed  by  the 
following  automatic  theorem  prover  for  the  propositional  logic,  which  proves  theorems  in 
the  propositional  logic  by  symbolically  rewriting  them  into  conjunctive  normal  form  and 
then  testing  each  disjunction  for  the  occurrence  of  a  proposition  and  its  negation; 

(d*ein«  $and  '$and) 

(d*£ln«  $or  '$or) 

(daflxw  $not  ' $not) 

(daflxM!  ($or)  «F) 

(de£ln«!  ($or  ...a($not  x)  ..Jb  x  ...c)  #t) 

(<te£liM!  ($or  ...a  x  ..Jb($not  x)...c)  #t) 

(de£lne!  ($ox  ...a  #t  ..l>)#t) 

(da£lzM!  ($or  ...a($or  ..Jb}...c)  ($or  ...a  ..2>  ».c)} 

(da£lna!  ($or  ...a($and  x  ..Jb)...c) 

($ajid($or  ...a  x  ...c)  ($or  ...a($aDd  „Jb)...c))) 

(da£ln«!  ($and)  #t) 

(da£lna!  ($and  ...a  #t  ..Jb)  ($and  ...a  ..Jb)) 

(da£ln«!  ($not  ($or  ...(!do(l  1  n)  (!ra£  1  x) ) ) ) 

($and  ...(!do(l  1  n)  ($not(!re£  1  x) ) ) ) ) 


(d*£la«!  ($not  ($and  ...(!do(l  1  n)(!r«£  1  x) ) ) ) 

($ox  ...(!do(l  1  n)  ($not(!x«£  i  x) ) ) ) ) 

(d»£iJM!  ($not  ($not  x) )  x) 

(d*£liM!  (Ispllxa  X  y)  ($ox($nofc  x)y)) 

(d*£lM!  (1££  X  y)  ($and(l]iipllas  x  y)  (inpllas  y  x) ) ) 

The  first  three  definitions  define  $and,  $or,  and  $not  to  be  symbolic.  Because  of 
the  cuts  on  all  the  succeeding  deHnitions,  the  effect  of  these  rules  is  to  return  these 
symbolic  values  only  if  no  other  definition  is  applicable.  T^e  next  six  definitions  detine 
properties  of  $or,  nairoly  that  $or  of  no  arguments  is  #£,  left  and  right  inverses,  the  zero 
law  of  $ox,  associativity,  and  distribution  $or  over  $«nd.  The  next  two  definitions  define 
properties  of  $and,  namely  that  Sand  of  no  arguments  is  #t  and  the  identity  law.  The 
next  three  definitions  are  deMorgans  laws  and  the  law  of  double  negation.  The  last  two 
definitions  are  the  definitions  of  Inpiiss  and  l££. 

In  this  program  each  of  the  variables:  $and,  $ox  and  $not  is  used  both  as  a 
procedure  and  as  a  sj^bolic  data  structure  to  which  other  definitions  are  applied.  For 
example,  ^e  $or  distribution  law  uses  $and  as  a  data  structure,  the  $or  associativity  law 
UKS  $or  itself  as  a  data  structure,  and  the  $or  inverse  laws  uses  $not  as  a  data  structure. 
Since  these  variables  are  also  used  as  procedures,  they  can  be  said  to  be  used  as  both 
procedures  god  data  structures.  Being  able  to  treat  variables  as  both  data  structures  and 
procedures  is  ari  important  capability  for  describing  the  semantics  of  complex  domains 
such  as  manufacturing  enterprises.  There  is  a  parallel  trend  in  computing  systems  towards 
a  merging  of  data  structures  and  procedures. 

This  program  can  be  used  to  prove  theorems  in  propositional  logic  when  the 
variables  in  the  theorem  are  given  symbolic  values.  For  example  the  variables  a,  b,  c  may 
be  defined  to  be  symbolic  values  as  follows: 

(da£li>«  a  _a) 

(da£ln«  b  3>) 

(de£ln«  c  ~c) 

Evaluating  the  following  theorem  then  results  in  #t : 

(ijBplle8($and(liBplles  a  b)  (iaplles  b  c)  (Ixoplles  c  a) 

($or  a  b  c)) 

($and  a  b  c)))  =>  #t 

33  Overview  of  Logistica 

A  Logistica  program  denotes  a  function  which  maps  a  tuple  of  streams  into  a 
stream.  A  stream  (or  'lazy  list')  is  either  empty  or  an  order^  pair  consisting  of  a  'head' 
and  'tail'.  The  head  is  a  data  object.  The  tail  is  either  a  stream  or  a  'promise'.  A  promise  is 
a  procedure  that  when  executed  produces  the  stream  representing  [die  rest  of]  the  original 
stream.  The  fact  that  a  Logistica  program  is  a  function  from  a  tuple  of  streams  to  a  stream 
can  in  numy  cases  be  ignored,  however.  Instead,  we  can  take  a  conceptually  simpler, 
more  t^itional  view  that  Logistica  is  a  function  that  maps  a  tuple  into  a  value.  This 
latter  view  will  generally  be  taken  outside  of  this  section.  However,  precision  sometimes 
requires  one  to  speak  of  Logistica  in  terms  of  its  underlying  streams. 

A  user  of  Logistica  writes  a  program  as  a  scries  of  definitions  and  an  expression 
denoting  the  function  from  a  tuple  of  streams  to  a  stream.  Multiple  definitions  for  each 
symbol  arc  allowed.  The  expression  produces  multiple  values,  each  one  being  an  item  in 
the  result  stream.  The  user  does  not  need  to  explicitly  deal  with  streams,  however,  since 
the  stream-handling  process  is  built  into  Logistica's  expression  evaluation.  We  call  the 
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resultant  stream  a  'control  stream'.  We  do  this  to  avoid  confusing  it  with  streams  that  the 
user  explicitly  creates  as  data  objects.  These  latter  objects  we  simply  call  'streams'. 

Control  streams  are  essential  for  building  deduction  systems  because  at  any  given 
point  in  a  deductive  process  it  is  usually  possible  to  apply  any  number  of  different 
deduction  steps,  each  one  leading  to  a  different  result.  Streams  capture  this  notion  of 
deductive  alternatives  by  allowing  each  value  of  the  control  stream  to  represent  an 
altmative  deductive  result. 

Various  amounts  of  control  may  be  exerted  over  the  creation  of  the  control 
stream.  If  no  restrictions  are  placed  on  the  execution,  then  all  possible  alternatives  are 
produced.  A  branch  of  the  deduction  may  be  eliminated  if  one  of  the  steps  returns 
'failure',  i.e.  the  empty  stream.  Alternatives  at  a  given  point  which  have  not  yet  been  tried 
may  be  'cut'  —  either  explicitly,  or  by  specifying  rules  to  be  used  to  determine  when  and 
what  to  cut.  Cut  alternatives  will  never  be  executed  nor  do  they  contribute  to  the  creation 
of  the  resulting  control  stream.  Specific  solutions  may  be  selectively  produced  by 
transforming  the  control  stream  into  an  ordinary  stream,  i.e.,  an  object  that  can  be  directly 
manipulated. 

A  class  of  potential  deduction  steps  is  encoded  as  a  procedure.  In  addition  to 
procedures  representing  total  functions  abstracted  with  a  list  of  unique  formal  parameters, 
Logistica  allows  procedures  representing  partial  functions  abstracted  with  a  list  of 
patterns  that  control  when  a  procedure  applies  to  a  particular  tuple  of  data.  These  patterns 
include  variable,  literal,  list  structure,  list  search  (segment  variables),  and  tree  search 
patterns  (schemators).  Because  some  patterns  may  match  in  more  than  one  way,  the 
patterns  may  contribute  to  alternative  paths  of  execution.  The  application  of  lambda 
abstractions  is  done  by  pattern-matching  of  the  patterns  against  the  input  arguments. 

In  Logistica  arbitrary  data  structures  may  be  applied  to  arguments.  When  the  data 
structure  is  not  an  abstraction,  the  tuple  containing  the  data  structure  followed  by  the 
arguments  is  returned.  This  allows  symbols  to  function  both  as  procedures  and  as  data 
structures  at  the  same  time  and  facilitates  symbolic  computation  ( as  noted  earlier  above). 

These  features  while  powerful  in  themselves,  are  integrated  with  the  language 
Scheme,  a  popular  LISP  dialect.  This  integration  gives  the  programmer  a  seamless  and 
natural  progression  of  tools,  from  the  straightforward  functional  progranuning  approach 
of  LISP  to  the  powerful  and  highly-descriptive  expression  of  alternative  computations 
afforded  by  Logistica.  A  brief  description  of  the  Scheme-like  features  of  Logistica 
follows. 

Following  ALGOL  and  Scheme,  Logistica  is  a  statically-scoped  programming 
lan^age.  Each  use  of  a  variable  is  associate  with  a  lexically-apparent  binding  of  that 
variable.  For  this  reason  static  scoping  is  also  called  lexical  scoping. 

Logistica  has  latent  as  opposed  to  manifest  types.  Types  are  associated  with 
values  rather  than  with  variables.  Some  authors  refer  to  languages  with  latent  types  as 
'weakly-typed'  or  'dynamically-typed'  languages.  Other  languages  with  latent  types  are 
Scheme,  Dylan,  APL,  Snobol,  and  other  dialects  of  LISP.  Ltmguages  with  manifest  types 
(stnnetimes  referred  to  as  'strongly-typed'  or  'statically-typed'  languages)  include  AL<^L 
60,  Pascal,  and  C. 

The  values  of  Logistica  expressions  are  called  'objects'.  This  use  of  the  term 
object  in  this  context  predates,  and  should  not  be  confused  with,  its  use  in  object-oriented 
programming  languages.  All  objects  created  in  the  course  of  a  Logistica  computation, 
including  procedures  and  continuations,  have  unlimited  extent.  No  Logistica  object  is 
ever  destroyed.  The  reason  that  Logistica  does  not  (usually)  run  out  of  storage  in  memory 
is  that  it  reclaims  the  storage  space  occupied  by  an  object,  if  the  object  cannot  possibly 
matter  to  any  future  computation.  This  is  a  more  sophisticated  form  of  what  is  commonly 
called  'garbage  collection'  in  most  LISP  environments.  Other  languages  in  which  most 
objects  have  unlimited  extent  include  APL,  Scheme,  Dylan,  and  other  LISP  dialects. 


Logistica  procedures  are  objects  in  their  own  right.  Procedures  can  be  created 
dynamically,  stor^  in  data  structures,  returned  as  results  of  procedures,  and  so  on.  Other 
languages  with  these  properties  include  Scheme,  Dylan,  Common  LISP  and  ML. 

Arguments  to  Logistica  procedures  are  always  passed  by  value,  which  means  that 
the  actual  argument  expressions  are  evaluated  before  the  procedure  gains  control,  whether 
the  procedure  needs  the  result  of  the  evaluation  or  not.  Scheme,  ML,  C,  and  APL  are  four 
other  languages  that  always  pass  arguments  by  value.  This  is  distinct  from  the  'lazy- 
evaluation'  semantics  of  Haskell,  or  the  'call-by-name'  semantics  of  ALGOL  60,  where  an 
argument  expression  is  not  evaluated  unless  its  value  is  needed  by  the  procedure. 

In  addition  to  procedures,  Logistica  has  objects  called  'macros'.  Macros  receive 
their  arguments  unevaluated.  The  environment  for  macros  is  taken  from  the  calling 
environment,  and  is  augmented  with  the  macro's  parameters  and  local  definitions.  Like 
procedures,  macros  produce  many  values.  Each  value  is  re-evaluated  in  the  calling 
environment.  Macros  can  be  used  to  define  new  special  forms  and  to  simulate  normal- 
(Hder  evaluation. 

Logistica's  model  of  arithmetic  follows  Scheme  and  is  designed  to  remain  as 
independent  as  possible  of  the  particular  ways  in  which  numbers  are  represented  within  a 
computer.  In  Logistica  every  integer  is  a  rational  number,  every  rational  is  a  real,  and 
every  real  is  a  complex  number.  Thus  the  distinction  between  integer  and  real  arithmetic, 
so  imponant  to  many  programming  languages,  does  not  appear  in  Logistica.  In  its  place 
is  a  distinction  between  exact  arithmetic,  which  corresponds  to  the  mathematical  ideal, 
and  inexact  arithmetic  on  approximations.  As  in  Common  LISP,  exact  arithmetic  is  not 
limited  to  integers. 

3.4  The  Nonmonotonic  Rule  System:  NONMON 

NONMON  is  a  set  of  Logistica  rules  which  implements  nonmonotonic  reasoning 
about  actions.  Before  explaining  NONMON,  it  is  important  to  first  explain  what 
nonmonotonic  reasoning  is  and  how  this  differs  from  the  monotonic  reasoning  carried  out 
in  classical  first-order  logic.  First-order  inference  is  monotonic:  given  a  set  of  sentences 
A,  the  inferences  that  can  be  drawn  from  A  are  a  subset  of  the  inferences  that  can  be 
drawn  from  the  set  A"0',  where  0  is  a  sentence.  In  contrast  to  this,  nonmonotonic 
reasoning  allows  that  inferences  that  can  be  drawn  from  A  may  not  be  a  subset  of  the 
inferences  that  can  be  drawn  from  A"0'.  Typically,  the  reason  for  this  lack  of 
monotonicity  is  that  such  systems  allow  inferences  to  be  made  in  the  presence  of 
incomplete  information.  We  call  such  inferences  'default  inferences'.  For  example, 
considCT  the  case  where:  Clyde  is  a  raven,  Claire  is  an  albino  raven,  ravens  are  normally 
black,  but  albino  ravens  are  not  black  ravens.  Under  classical  first-order  logic  with 
monotonic  inference,  we  are  not  allowed  to  conclude  anything  about  the  color  of  Clyde. 
If  we  allow  nonmonotonic  inference,  then  because  we  know  of  no  other  facts  to  the 
contrary,  we  can  conclude  that  Clyde  is  black  since  that  is  normally  the  case.  If  we  should 
later  add  the  sentence  (corresponding  to  0)  that  Clyde  is  albino,  then  we  are  no  longer 
allowed  to  conclude  that  Clyde  is  black,  and,  hence,  our  reasoning  method  is 
nonmonotonic,  i.e.,  Th(A)  <t  Th(Avj{0))  where  Th(A)  is  the  set  of  theorems  of  A  derivable 
through  classical  and  nonmonotonic  inference. 

Classical  flrst-<mler  logic  works  well  for  problems  in  mathematics  or  in  greatly 
simplified  models  of  the  real  world.  It  does  not  work  well  for  problems  which  are  too 
large  or  too  complicated  to  completely  formalize,  nor  does  it  work  well  for  problems 
dealing  with  change  over  time,  nor  for  problems  where  not  all  information  is  known,  such 
as  explanation.  A  number  of  logical  systems  have  therefore  been  proposed  for  carrying 
out  nonmonotonic  reasoning,  but  most  of  these  proposed  solutions  lack  effective  proof 
theories  (i.e.,  formal  descriptions  of  their  rules  of  inference  represented  in  a  recursive 
manner)  and  are  merely  semantic  descriptions  of  the  'valid'  inferences.  Such  systems  are 
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based  on  carrying  out  computations  over  infinite  sets  of  sentences  and  are  completely 
computationally  intractable.  However,  we  have  developed  a  monotonic  theory  of 
nonmonotonic  reasoning  which  has  a  recursive  proof  theory  and  which  has  in  fact  been 
implemented  as  a  set  of  Logistica  rules.  This  theory  is  our  modal  logic  Z  which  is  a 
fragment  of  second-order  modal  quantificational  logic,  involving  quandfication  over 
propositions  but  not  over  properties.  It  is  a  recursively  axiomatized  logic  with  a 
recursively  enumerable  set  of  theorems.  It  is  like  classical  logic  except  that  it  allows  one 
to  express  notions  of  what  is  possible  with  respect  to  a  body  of  evidence.  For  example,  if 
K  is  the  theory  about  Clyde  and  Raven  articulated  in  the  previous  paragraph  where  the 
wnten^  that  "Ravens  are  normally  black"  is  expressed  as  the  modal  logic  sentence:  'If  it 
is  possible  with  respect  to  K  for  a  raven  to  be  black,  then  that  raven  is  black”,  then  by  the 
laws  of  the  modal  logic  Z  we  can  mechanically  infer  that  K  entails  that  Clyde  is  black. 
Likewise,  if  J  is  the  2nd  theory  articulated  in  the  previous  paragraph,  where  it  is 
essentially  K  augmented  with  the  additional  fact  that  Clyde  is  an  albino,  J  will  not  entail 
that  Clyde  is  black. 

The  reason  nonmonotonic  reasoning  is  important  for  building  automated 
manufactunng  and  design  systems  is  that  engineers  and  designers  have  a  deep  intuitive 
understanding  of  defaults  about  the  mechanical  actions  of  manufacturing  processes,  as 
well  as  the  mental  actions  involved  in  both  the  design  and  manufacturing  processes. 
Thus,  if  useful  automatic  aids  for  design  and  manufacturing  are  to  be  implemented,  they 
too  will  need  to  'understand'  these  implicit  assumptions.  In  order  to  reason  about  actions, 
a  set  of  rules  called  NONMON  has  been  implemented  in  Logistica  for  purposes  of 
enabling  nonmonotonic  reasoning  about  actions.  These  rules  are  essentially  derived  rules 
of  inference  of  the  modal  logic  Z. 

We  illustrate  below  some  simple  examples  of  NONMChTs  ability  to  reason  about 
actions.  For  the  readers  convenience  all  the  examples  are  expressed  in  English.  The  actual 
logical  representations  used  by  NONMON  are  described  in  a  related  technical  report 
entitled,  "A  Logistica  Deduction  System  for  Solving  NonMonotonic  Reasoning  Problems 
using  the  Modal  Logic  Z'  [Brown 1993e].  The  areas  of  reasoning  include:  reasoning  about 
the  future;  reasoning  about  the  past;  counterfactual  reasoning;  and  reasoning  about 
concurrent  actions. 

3.4.1  Reasoning  About  the  Future 

Reasoning  about  the  future  involves  the  prediction  of  the  results  of  carrying  out  a 
sequence  of  actions  starting  from  some  initial  situation. 


Assumptions:  After  an  action  is  performed,  things  normally  remain  as  they  were. 

A  block  is  on  the  table  if  and  only  if  it  is  not  on  the  floor. 

When  the  robot  grasps  a  block,  the  block  will  be  normally  in  the  hand. 
When  robot  moves  a  block  onto  the  table,  the  block  will  be  normally  on 
the  table. 

Moving  a  block  that  is  not  in  the  hand  is  an  exception  to  this  rule. 
Initially  block  A  is  not  in  the  hand. 

Initially  block  A  is  on  the  floor. 

Conclusions:  After  the  robot  grasps  block  A,  waits,  and  then  moves  it  onto  the  table, 

the  block  will  be  on  the  table. 


3A2  Reasoning  About  the  Past 


Reasoning  about  the  past  involves  filling  in  the  missing  details  or  giving  a 
plausible  explanation  of  what  occurred  in  the  past,  from  an  incomplete  partial  description 
of  what  hap^ned. 

Problem  2.  Unknown  Initial  Conditions 


Assumptions:  After  an  action  is  performed,  things  normally  remain  as  they  were. 

When  the  robot  grasps  a  block,  the  block  will  be  normally  in  the  hand. 
When  the  robot  moves  a  block  onto  the  table,  the  block  will  be  normally 
on  the  table. 

Moving  a  block  that  is  not  on  the  hand  is  an  exception  to  this  rule. 
Itatially  block  A  was  not  on  the  table. 

After  the  robot  moved  A  onto  the  table  and  then  waited,  A  was  on  the 
table. 

Conclusion:  Irtitially  A  was  in  the  hand. 

Problem  3.  Unknown  Acrions 


Assumptions: 


Conclusions: 


After  an  action  is  performed,  things  normally  remain  as  they  were. 
When  the  robot  grasps  a  block,  the  block  will  be  normally  in  the  hand. 
When  the  robot  moves  a  block  on  to  the  table,  the  block  will  be 
normally  on  the  table. 

Moving  a  block  that  is  not  in  the  hand  is  an  exception  to  this  rule. 
Irtitially  block  A  was  not  on  the  table. 

Irtitially  block  A  was  not  in  the  hand. 

After  the  robot  grasped  some  block  and  then  moved  some  block  onto  the 
table, 

A  was  on  the  table. 

The  block  that  was  grasped  was  A. 

The  block  that  was  moved  on  the  table  was  A. 


Problem  4.  Actions  of  Unknown  Kinds 

Assumptions:  After  an  action  is  performed,  things  normally  remain  as  they  were. 

When  the  robot  grasps  a  block,  the  block  will  be  normally  in  the  hand. 
When  the  robot  moves  a  block  onto  the  table,  the  block  will  be  normally 
on  the  table. 

Moving  a  block  that  is  not  in  the  hand  is  an  exception  to  this  rule. 
Irtitially  block  A  was  not  on  the  table. 

Irtitially  block  A  was  not  in  the  hand. 

After  the  robot  performed  two  actions,  A  was  on  the  table. 

Conclusions:  The  first  of  the  two  actions  was  grasping  A . 

The  secotid  of  the  two  actions  was  moving  A  onto  the  table. 

Problem  5.  Unknown  Order  of  Actions 


// 


Assumptions:  After  an  action  is  performed,  things  normally  remain  as  they  were. 

When  a  person  accepts  a  job  offer  from  some  employer,  he  will  be 
employed  by  that  employer. 

If  Bill  is  offered  a  job  at  Berkeley  or  at  Stafford  when  he  is 
unetnployed,  he  will  accept  it. 

Bill  is  currently  unemployed. 

Conclusion:  After  Bill  is  offered  jobs  at  Berkeley  and  Stanford  at  two  different 

instants  of  time,  he  will  be  employed  either  by  Berkeley  or  by  Stafford. 


Assumptions: 


Conclusion: 


After  an  action  is  performed,  things  normally  remain  as  they  were. 
When  the  robot  moves  a  block  to  another  location,  the  block  will  be 
normally  at  that  location. 

After  the  robot  moved  a  block  to  Location  1  and  then  to  Location  2,  the 
block  changed  its  color. 

The  block  changed  its  color  only  once,  either  cfter  the  first  move,  or 
cfter  the  second. 


Assumptions: 


Conclusion: 


When  the  robot  moves  a  block  to  another  location,  the  block  will  be 
normally  at  that  location. 

After  the  robot  moved  block  A  onto  the  table,  and  then  moved  block  B 
onto  the  table,  at  most  one  of  the  blocks  A,  B  was  on  the  table. 

After  the  two  actions  were  performed,  exactly  one  of  the  blocks  A,  B 
was  on  the  table. 


3.43  Reasoning  About  Actions  That  Might  Have  Happened:  Counterfactual 
Reasoning 

Counterfactual  reasoning  is  reasoning  about  what  might  have  been,  and  usually 
takes  the  form,  "suppose  that  x  were  to  be  the  case,  then  y."  For  this  statement  to  be  a 
counterfactual  conditional,  x  must  be  counterfactual,  i.e.,  contrary  with  the  present 
situation. 
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Assumptions: 


Conclusion: 


After  an  action  is  performed,  things  normally  remain  as  they  were. 
When  the  robot  moves  a  block  to  another  location,  the  block  will  be 
normally  at  that  location. 

After  the  robot  moved  block  A  to  Location  1,  block  B  changed  its  color. 
Block  B  would  have  changed  its  color  if  the  robot  had  moved  A  to 
Location  2. 


3.44  Reasoning  About  the  Future  in  the  Presence  of  Concurrent  Actions 

CtMtcunent  actions  for  our  purposes  are  those  actions  that  occur  during  the  same 
transition  from  one  state  to  the  next  At  present  there  seems  to  be  no  completely  formal 
work  on  nmimonotonic  reasoning  about  concurrent  actions. 


Assumptions:  When  two  actions  are  performed  concurrently,  their  effects  are 

normally  combined. 

When  the  robot  moves  a  block  to  another  location,  the  block  will 
normally  be  at  that  location. 

Conclusion:  After  block  A  is  moved  to  Location  1  and  block  B  is  concurrently  moved 

to  Location  2,  A  will  be  at  Location  1  and  B  will  be  at  Location  2. 

Problem  9a.  Conflicting  Concurrent  Actions  I 

Assumptions:  When  two  actions  are  performed  concurrently,  their  effects  are 

normally  combined. 

When  the  robot  moves  a  block  to  another  location,  the  block  will 
normally  be  at  that  location. 

Corxlusion:  After  block  A  is  moved  to  Location  1  and  block  A  is  concurrently  moved 

to  Location  2,  either  A  will  be  at  Location  1  or  A  will  be  at  Location  2. 

Problem  9b.  Conflicting  Concurrent  Actions  n 

Assumptions:  When  two  actions  are  performed  concurrently,  their  effects  are 

nomudty  combined. 

When  the  robot  moves  a  block  to  another  location,  the  block  will 
normally  be  at  that  location. 

Conclusion:  After  block  A  is  moved  to  Location  1  and  block  B  is  concurrently  moved 

to  Location  1,  either  A  will  be  at  Location  1  or  B  will  be  at  Location  1. 

4.  Approach  Used  to  Design  and  Develop  Logistica 

As  previously  mentioned  in  Section  2.,  Logistica  is  a  tool  used  to  develop  hi^- 
level  reasmiing  systems  for  manufacturing  and  management  applications.  A  Logistica 
System  is  thus  Logistica  plus  the  high-level  rules  modeling  such  reasoning.  Thus,  our 
overall  approach  used  in  developing  such  reasoning  systems,  was  to  abstract  out  the 
common  reasoning  functionality  involved  in  such  reasoning  and  to  embed  this 
functionality  into  the  Logistica  language.  We  then  implemented  and  documented  this 
language,  and  tested  it  on  a  very  wide  range  of  reasoning  problems  to  ensure  its 
generality  and  usefulness.  The  design  of  the  language  is  described  in  the  Logistica 
Reference  Manual  [Brown93a]  and  the  wide  range  of  reasoning  easily  expressible  in  it  is 
described  in  the  Logistica  I^grammer's  Manual  [Biown93d]. 

There  are  three  main  lessons  to  be  learned  from  the  success  of  this  language 
develqptnent  effort.  The  flrst  lesson  is  that  it  is  important  to  abstract  out  basic  reasoning 
capalnlities  and  to  embed  them  into  the  underlying  language,  as  this  allows  one  to  avoid 
in^lementing  these  c^bilities  over  and  over  again.  This  capability  is  precisely  what  let 
us  succeed  in  devel^ing  the  NONMON  nonmonotonic  rule  systems  for  reasoning  about 
actions.  Without  this  cqtability  for  quickly  implementing  such  sophisticated  reasoning 
systems,  this  project  would  not  have  been  able  to  be  completed.  In  other  wwds, 
traditional  {vogramming  methods  that  did  not  take  advantage  of  generic  or  reusable 
reasoning  rules  would  have  been  entirely  inadequate  from  both  a  technological  and 
methodological  standpoint. 

The  second  lesson  we  learned  was  that  new  programming  systems  are  greatly 
enhanced  if  their  syntax  and  semantics  can  both  be  viewed  as  a  logical  extension  from 
previous  elegantly  designed  systems.  As  we  started  the  development  of  Lo^stica,  we 
initially  used  our  own  LlSP-like  language  for  Logistica  syntax.  However,  within  a  few 
mondis,  it  became  clear  to  us  that  Logistica  should  be  ba^  as  much  as  possible  on  the 
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most  ttoHctically  elegant  dialect  of  LISP,  a  dialect  known  as  Scheme.  Thus  in  evaluating 
Logisdca  expressions,  even  though  expressions  may  have  multiple  values  in  Logisdca 
they  look  like  the  single-valued  expressions  of  Scheme.  Likewise  the  pattern-matching 
capabilities  of  Logistica  are  implemented  as  patterns  in  the  formal  parameter  list  of  a 
function  and  are  an  extension  of  what  is  normally  allowed  there.  Because  Logistica  looks 
like  the  well-known  Scheme  dialect  of  LISP  (even  though  it  is  much  more  sophisticated 
semantically),  this  facilitates  its  acceptance  by  scientists  and  engineers  because  they  do 
not  have  to  learn  an  entirely  new  language  that  does  many  of  the  same  things  as 
languages  they  already  know  do.  They  essentially  have  only  to  learn  the  differences 
which  make  Logistica  mcm  expressive  and  more  general. 

The  third  lesson  learned  is  that  our  users  tind  significant  value  both  in  Logistica 
itsetf  and  in  the  ideas  and  technologies  inherent  in  Logistica.  For  example,  even  £ough 
Allied  Signal  has  purchased  the  Logistica  system  with  its  nonmonotonic  rule  system 
NONMON  for  dealing  with  reasoning  about  actions,  it  has  also  found  significant  use  for 
using  Logistica  as  an  implementation  language  for  major  aspects  of  its  manufacturing 
solid  modeling  reasoning.  This  application  is  independent  of  the  NONMON  rule  system. 
Likewise,  Ontek  has  found  that  the  deduction  technology  of  Logistica  itself  is  useful  to 
handle  a  number  of  system  problems  in  their  knowledge  representation  system.  These 
implications  of  Logistica  are  described  in  the  next  section. 

5.  Applications  of  Logistica 

During  the  course  of  this  project  Logistica  was  applied  in  two 
industrial/commercial  settings.  One  application  was  at  Ontek  Corporation  as  part  of  the 
development  of  its  PACTS  software  system  and  the  other  was  at  the  DOE's  Kansas  City 
Plant  run  by  Allied  Signal  Aerospace  as  part  of  its  engineering  and  manufacturing 
operations.  These  applications  of  Logistica  are  described  in  sections  5.2  and  5.3, 
respectively.  Section  5.1  describes  the  overall  objectives  and  criteria  for  applying 
Lo^tica  under  this  project. 

5.1  Objectives  and  Criteria  for  Application  of  Logistica 

The  purpose  of  applying  Logistica  under  this  Phase  II  SBIR  project  was  to 
establish  a  'proof  of  principle'.  For  this  reason  we  picked  two  very  different  applications: 
me  as  an  embedded  theorem  prover  to  support  a  very  general,  very  powerful  enterprise 
information  integration  platform  under  development  as  part  of  another  Air  Force 
ManTech  program;  and  one  to  directly  support  representation  of  complex  end-user  rules 
in  a  real-world  manufacturing  engineering  domain  (namely  process  planning).  Hie  latter 
demonstration  project  was  chosen  because  Inte^ted  Product  Piwess  Development 
(IPPD)/Concurrent  Engineering  (CE)  is  becoming  a  critical  productivity-enhancing 
appn^h  in  a  number  of  commercial  and  aerospace/defense  industries.  IPPD/CE  requires 
sophisticated  tools  to  support  description  of  the  information  entities,  processes  and 
business  rules  used  by  an  enterprise  in  the  course  of  designing,  manufacturing  and 
suppming  its  products.  Lo^stica  lends  itself  to  the  description  of  such  business  rules, 
and  to  the  use  of  such  descriptions  by  automated  reasoning  systems  to  suppon  decision¬ 
making  in  the  enterprise.  These  two  applications  are  desciib^  respectively  in  sections  5.2 
and  5.1 

5.2  Application  to  Ontek's  PACIS  Under  ITKM  CDIT 

5.2.1  Technical  Requirements  for  PACIS  under  ITKM  CDIT 


Under  the  ITKM  CDIT  project,  Ontek  has  identified  end-user  needs  and 
requirements  for  production-viable  Integration  Toolkits  and  Methods  -  Corporate  Data 
Integration  Tools  (ITKM  CDIT).  These  tools  essentially  comprise  an  enterprise 
information  integration  platform  based  on  the  ANSI/ISO  Three-Schema  [Database 
Management]  Architecture  (i.e.,  using  external,  conceptual  and  internal  schemas)  [ISO, 
1987;  Tsichritzis  and  Klug,  1978].  The  technology  is  being  operationalized  using  Ontek 
Cmporation's  Platform  for  the  Automated  Ccmstruction  of  Intelligent  Systems  (PACIS). 
‘Ptoduction  viable'  means  that  ITKM  CDIT  technologies  must  meet  or  exceed  the 
performance  capabilities  of  existing  technologies  and  be  sustainable  in  large-scale, 
heterogeneous  information  resource  environments.  Performance  and  sustainability 
comprise  the  two  primary  end-user  or  'enterprise  business-level'  requirements. 

Requirements  for  performance  deal  both  with  the  local  performance  of  the  ITKM 
CDIT  toolkit  and  its  ability  to  optimize  the  performance  of  the  foreign  systems  mth 
which  it  must  interact  Several  sustainability  requirements  address  the  subsumptive 
integration  of  commercial  database  management  systems  (DBMSs)  and  their  associated 
databases.  Included  are  requirements  for  compatibility  with  existing  computing 
environments,  as  well  as  functional  capabilities  to  support  direct,  dynamic,  and  ad-hoc 
access  and  update  from  the  PACIS  platform  to  data  stored  in  commercially-available 
DBMSs.  Examples  of  such  database  management  systems  include  IBM's  IMS  and  pB2, 
and  Oracle  Corptnation's  ORACLE.  Object-oriented  DBMSs  are  also  being  utilized  in  an 
increasing  number  of  production  DBMS  environments,  and  this  trend  is  expected  to 
ramp-up  dramatically.  The  access  capability  must  therefore  be  applicable  to 
heterogeneous  environments  that  run  the  gamut  from  'flat'  file  management  systems, 
throuj^  traditional  hierarchical,  network  and  relational  DBMSs,  to  emerging  object- 
mien^  DBMSs.  This  access  should  be  u%r  transparent  —  i.e.,  end-users  should  not 
have  to  have  any  knowledge  of  the  location  of  the  data  or  the  underlying  systems  that 
manage  the  databases.  The  toolkit  m*'.st  also  do  more  than  simply  access  the  data  in 
existing  DBMS  environments;  an  enterprise  information  integration  platform  must  be 
able  to  dynamically  interact  or  interoperate  with  those  legacy  systems.  This  includes  the 
requirement  to  p^mm  and  propagate  updates  across  a  network  of  distributed,  but 
intemted,  systems.  Other  performance  and  sustainability  requirements  deal  with  the 
toolut  itself,  in  particular  the  need  for  the  individual  components  or  tools  to  be  tightly 
integrated  so  that  from  a  user  standpoint,  the  toois  can  be  viewed  simply  as  elements  of  a 
complete  suite  of  tools  or  a  unified  toolkit. 

Based  <m  these  two  end-user  requirements  for  performance  and  sustainability  at 
the  'enterprise  business  level',  Ontek  then  identified  detailed  5  technical  requirements  at 
the  'techirology  level'. 

1.  One  key  technology-level  requirement  is  for  Reference  Mediation.  Reference 
mediation  is  important  for  optimizing  performance,  by  enabling  the  selection  of 
different  access  methods  depending  on  the  nature  of  the  data  being  accessed  and 
the  drna  management  environment  in  which  it  resides.  This  is  especially  critical  in 
large-scale  database  environments,  like  one  would  expect  to  find  in  integrated 
enterprises. 

2.  A  second  technology-level  requirement  is  the  capability  to  compile  a  single 
PACIS  operaticm,  such  as  an  end-user  query,  into  a  complex  or  collection  of 
subqueries  expressed  in  the  particular  DBMS  data  manipulation  languages 
(DN^)  of  the  various  databases  targeted  by  the  query.  This  capability  is  critical 
for  dir^t,  transparent,  dynamic,  ad-hoc  access  to  distributed,  heterogeneous 
databases  to  be  viable  in  a  large-scale  production  environment  —  i.e.,  it  is  critical 
for  p^ormance.  Examples  of  DMLs  are  DL/I  for  the  IMS  DBMS,  and  SQL  for 
the  ORACLE  and  DB2  DBMSs.  The  compiled  DMLs  must  also  be  tailored  to  the 
specific  computing  environments  (e.g.,  MVS/CICS,  UNIX,  etc.)  in  which  the 


DBMSs  reside.  The  compiled  subqueries  can  then  be  distributed  to,  stored  in,  and 
executed  on  the  machines  containing  the  target  databases. 

3.  A  third  important  technology-level  requirement  can  be  referred  to  as  Global 
Instantiation  —  for  sustainability,  the  tooUut  must  be  able  to  create  instances  (i.e., 
new  records)  in  systems  external  to  the  PACIS-based  data/knowledgebase, 
including  systems  in  the  enterprise's  existing  information  resources  environment. 

4.  A  fourth  technology-level  requirement,  mandated  by  the  end-user  requirement 
fOT  sustainability,  is  the  existence  of  a  Global  Condition  Handling  mechanism  to 
automatically  propagate  the  consequences  of  events  occurring  in  one  area  of  the 
system  across  other  system  elements  for  which  these  events  have  consequences. 

5.  The  fifth  major  technology  requirement,  is  for  Global  Presentation.  This 
capability  will  enable  the  various  ITKM  CDIT  technologies  to  operate  as  a  single 
lo^cal  toolkit  comprised  of  an  underlying  platform  (i.e.,  PACIS)  supponing 
multiple  functional  tools  which  provide  various  interrelated  services  such  as: 
conceptual  analysis  and  modeling;  enterprise  model  integration;  legacy  database 
query,  update  and  integration,  etc.  Tool  integration  imposes  more  detailed 
i^uirements  on  the  use  of  the  baseline  PACIS  representation  system,  and  drives 
the  requirement  for  a  new  global  environment  to  support  common,  unified 
graphic^  user  interfaces  (GUIs). 

Tlte  five  key  technical  requirements  described  in  the  previous  section,  particulariy 
the  coi^iler,  the  global  instantiation  capability  and  the  global  condition  handling 
capal^ty,  drive  a  sixth  important  technical  ^uirement  —  the  need  for  the  ITKM  CDIT 
toolkit  to  perform  Pattern-Directed  Invocation.  Like  the  other  five,  this  requirement  is 
also  necessary  to  meet  the  enterprise  business-level  requirements.  However,  the  first  five 
technical  requirements  may  be  considered  'vertical'  requirements  that  address  specialized 
areas.  There  are  some  inter-relationships  among  them,  but  they  can  be  thought  of  as 
fundamentally  distinct.  The  sixth  requirement,  on  the  other  hand,  is  a  'horizontal' 
requirement,  which,  while  addressing  distinct  functional  capabilities,  serves  to  enable  or 
suppOTt  the  capabilities  of  the  other  five  technical  requirements.  This  can  be  explained  in 
more  detail  as  follows: 

6.  The  sixth  technology-level  requirement  is  for  a  functional  capability  to 
perform  Pattern-Directed  Invocation.  The  problems  of  scope,  complexity, 
sustainability  and  performance  that  information  integration  raises  requires  new 
techniques  for  basic  system  operations  such  as  compilation,  condition  handling, 
inst^tiation  and  process  invocation.  The  melding  of  database  operations  — 
particularly  instantiation  —  and  traditional  programming  operations  requires 
pattm-directed  invocation.  As  noted  earlier,  a  compiler,  a  global  instantiation 
facility  and  a  global  condition  handling  facility  are  necessary  to  provide  the 
performance  and  sustainability  required  by  day-to-day  system  operations  in  a 
large-scale,  integrated  information  environment.  Even  the  construction  of  a 
compiler  for  PACIS,  as  well  as  the  creation  of  both  a  global  instantiation  facility 
a^  a  global  condition  handling  facility,  entail  that  PACIS  support  pattern- 
directed  invocatitui.  The  compiler  requires  pattern-directed  invocation  because  the 
language  translation  job  is  just  too  complicated  to  ^  building  it  using  purely 
deterministic  mthods.  The  global  instantiation  facility  and  the  global  condition 
handling  facility  require  pattern-directed  invocation  because  they  must  have  the 
ability  to  invoke  routines  based  on  the  current  state  of  the  system,  rather  than 
based  rni  a  previously-defined  calling  sequence. 


Two  lower-level  technical  requirements,  which  represent  further  refinements  of 
the  overall  requirement  to  support  pattern-directed  invocation,  have  also  been  identified. 
Existing  pattern-based  languages  such  as  PROLCXj  and  ML  allow  for  pattern-directed 
invocantMi,  but  with  certain  limitations.  These  limitations  must  be  overcome  in  order  to 
meet  other  mCM  CDIT  requirements  for  a  compiler,  a  global  instantiadon  capability  and 
a  global  condition  handling  capability.  The  additional  requirements  described  below  are 
ba^  partly  on  overcoming  the  limitations  of  existing  panem-based  languages. 

1.  Alow  multiple  matches  on  operations  and  definitions.  The  PACIS  compiler 
requires  this  capability  because  there  may  be  many  possible  target  code  solutions 
to  any  one  query,  and  deciding  which  one  is  best  for  the  purpose  at-hand  requires 
having  them  dl  available  at  the  same  time  for  comparison.  A  condition 
mechanism  requires  this  because  there  is  more  than  one  possible  action,  or 
condition  hanger,  that  may  be  invoked  during  a  fault  in  a  thr^-schema  database 
transaction.  For  example,  you  might  have  to  do  both  a  DB2  image  rollback  and  an 
IMS  checkpointAestart. 

2.  Support  dynamically-definable  interpreter  control  structures  —  This  will  be  a 
critical  capability  in  the  ITKM  CDIT  environment,  since  the  dynamic  semantics 
of  other  systems  must  be  subsumed  to  support  their  integration.  The  subsumption 
of  dynamic  semantics  includes  representing  and  eventudly  executing  the  control 
structures  these  disparate  systems  use.  These  systems  may  well  have  different 
meanings  for  the  same  control  structure  named  in  another  system.  This  puts  the 
burden  on  the  PACIS  interpreter  to  carry  multiple  definitions  of  control  structures. 

5  J  J  How  Logistica  Meets  ITKM  CDIT  Technical  Requirements 

Logistica  helps  meet  the  ITKM  CDIT  technical  requirements  by  providing  a 
working  system  which  satisfles  the  pattern-directed  invocation  requirements  described 
above  in  Section  S.3.1.  Use  of  Logistica  in  this  'proof  of  principle'  setting  has  indicated 
that  these  difficult  requirements  can  be  satisfied  to  a  sufficient  degree,  and  has  helped 
demonstrate  speciflcdly  how  one  might  go  about  implementing  this  capability  in  a 
production  version  of  an  enterprise  information  integration  system. 

A  copy  of  the  Logistica  system  was  delive^  to,  and  installed  at,  Ontek.  Ontek 
programmers  then  studied  the  logistica  system  and  determined  that  this  technology 
appeared  to  be  able  to  satisfy  many  of  the  requirements  for  a  pattern-directed  invocation 
capability.  AIR  worked  with  Ontek  staff  to  help  them  understand  the  basic  ideas  behind 
Lt^stica  and  to  explore  possible  ways  to  emb^  Logistica's  pattern-directed  invocation 
capability  within  Ontek's  C-based  PACIS  knowledge  representation  product.  Ontek  is 
currently  planning  to  reimplement  various  Logistica  functionality  in  C  as  pan  of  PACIS. 
AIR  will  be  provided  a  royalty  or  other  similar  compensation  ^m  the  sale  or  lease  of 
PAOS  software  incorporating  Logistica's  pattern-directed  invocation  capability. 

Two  specific  examples  of  how  Logistica  meets  the  required  pattern-directed 
invocation  requirements  of  PACIS  are  described  below: 

1.  The  Queens  example  described  in  Section  3.1  demonstrates  that  Logistica 
provides  for  multiple  matches  on  both  operations  and  data  as  required  for  the 
PACIS  condition  handler.  Logistica  provides  explicit  suppon  for  multiple 
matches  on  operation  definitions  and  multiple  input  states.  A  given  input  to  a 
pattern-direct^  interpreter  may  possibly  match:  none;  exactly  one;  or  many 
operation  definitions.  Also,  a  given  input  operation  may  have:  no  arguments; 
exactly  one  set  of  arguments  (one  input  state);  or  many  sets  of  arguments  (many 
input  states).  The  power  of  a  pattern-directed  invocation  mechanism  depends  on 
how  it  handles  the  possible  operation  matches  and  their  application  to  the  possible 


number  of  input  states.  Of  the  existing  pattern-based  languages  such  as  ML  and 
PROLOG,  Logistica  is  the  only  one  that  can  handle  all  of  the  possible  cases  of 
operation  matches  and  input  states.  In  ML,  for  instance,  even  if  there  are  several 
operation  definitions  which  match  the  input  pattern,  only  the  first  match  will  be 
returned.  This  means  that  ML  can  only  execute  one  of  possibly  many  definitions 
for  a  given  operation.  PROLOG  does  return  matches  of  multiple  operation 
definitions,  but  whether  one  or  many  operations  are  returned,  they  are  applied  to 
only  one  input  state.  In  the  case  where  there  are  many  operation  definition 
matches,  as  well  as  multiple  input  states,  Logistica  invokes  the  Canesian  cross- 
product  of  'operation  definitions  X  input  states'. 

2.  The  propositional  deduction  system  illustrates  that  Logistica  supports 
dynamically-definable  interpreter  control  structures  as  is  required  for  the 
subsumptive  requirements  of  PACIS.  Thus  Logistica  provides  dynamically- 
definable  interpreter  control  structures  whereas  older  languages,  such  as 
PROLOG,  'wire  down'  the  basic  syntactic  control  structures  they  use.  In  other 
words,  the  control  structures  of  these  other  languages  are  static.  Symbols  such  as 
'and'  are  primitive  and  have  only  one  definition.  In  Logistica,  even  these  basic 
control  structures  can  themselves  be  defined.  In  addition,  since  Logistica  allows 
for  multiple  definitions  of  operations,  the  control  structures  can  be  multiply- 
defined. 

In  summary,  Logistica  has  provided  Ontek  with  the  basis  for  its  required  pattern- 
directed  invocation  capability.  That  capability  can  now  be  operationalized  in  PACIS  and 
used  for  ITKM  CDIT  technologies.  TTiis  is  one  of  the  most  important  requirements  of 
Ontek's  ITKM  CDIT  project,  as  this  requirement  is  a  basic  enabling  requirement  for  the  5 
other  technological  requirements  of  the  project. 

In  early  1994,  Ontek’s  technologies  (which  include  logic  based  on  the  Logistica 
technology)  will  be  ready  for  demonstration.  Ontek  eventually  plans  to  commercially 
maritet  im^ucts  based  on  ITKM  CDIT  technology. 

5J  Deployment  into  Allied  Signal 

Logistica  has  been  deployed  (i.e.,  sold,  installed,  implemented  and  put  into 
operation)  for  Allied  Signal  Aerospace  at  the  Department  of  Energy's  (DOE's)  Kansas 
City  Plant.  The  business  transaction  took  the  form  of  a  sale  of  1  copy  of  Logistica 
running  on  a  SUN  SPARCstation,  and  the  sale  of  1  copy  of  the  nonmonotonic  rule 
system,  NONMON.  The  nonmonotonic  rule  system  was  implemented  in  Logistica  and 
makes  use  of  its  pattern-directed  invocation  capability  and  its  ability  to  represent  multiple 
values.  This  nonmonotonic  reasoning  capability  was  critically  ne^ed  by  Allied  Signal 
ftv  developing  an  automated  manufacturing  system. 

AlAough  Allied  Signal  originally  purchased  Logistica,  as  well  as  the  NONMON 
nonmonotonic  rule  set  written  in  Logistica,  for  use  in  understanding  and  representing  the 
results  of  mechanical  manufacturing  actions  and  mental  actions  involved  in  the  design 
process.  Allied  Signal  subsequently  discovered  that  Logistica  itself  (without  the 
NONMON  rule  set )  is  a  very  useful  language  for  implementing  translation  processes, 
and  fcnr  verifying  design  constraints  and  consistency.  In  fact,  they  have  found  Logistica  to 
be  so  useful  that  one  development  group  is  considering  rewriting  substantial  parts  of  their 
existing  manufacturing  system  in  the  Logistica  language.  The  decision  to  consider  this 
further  use  of  Logistica  was  made  despite  Allied  Signd's  considerable  past  investment 
and  experience  in  other,  less  powerful  languages.  It  was  felt  that  Logistica  offered  the 
potential  of  providing  much  needed  system  capabilities  which  could  not  be 
operationalized  (or  at  least  not  as  efficiently  and  cost-effectively)  using  existing 


technologies.  These  applications  of  Logistica  without  NONMON  are  briefly  described  in 
Sections  5.3.1  and  5.3.2  below.  The  originally-envisioned  project,  a  longer-term 
application  of  Logistica  coupled  with  NONMON,  is  described  in  Section  S.3.3  below. 

S.3.1  Machining  Form  Feature  Translation  Project 

Under  the  National  Inidadve  for  Product  Data  Exchange  (i.e.,  NIPDE),  the  DOE's 
Kansas  City  Plant  run  by  Allied  Signal  is  currently  working  with  a  number  of  other 
companies  to  create  a  single  unified  model  of  machining  form  features.  This  work  is 
being  carried  out  in  andcipation  of  creadng  new  STEP  (Standard  for  The  Exchange  of 
Product  model  data)  application  protocols  in  the  area  of  form  features  such  as  pockets, 
holes,  slots,  bends,  and  chamfers.  The  appiicadon  protocols  take  the  form  of  'context- 
driven  integrated  model*  (CDIM)  speciflcadons.  The  basic  idea  is  to  have  a  company 
create  product  designs  which  are  represented  in  a  standard  way,  so  that  they  can  be 
transmitted  to  and  used  by  other  companies  such  as  subcontractors,  vendors,  customers  or 
support  organizadons.  This  work  involves  the  following  two  steps: 

1.  First,  the  Navy  RAMP  Product  Translation  System  (i.e.,  RPTS)  project  at 
the  South  Carolina  Research  Authority  (SCRA)  and  Grumman  Data  Systems  is 
providing  a  source  of  machining  form  feature  files  expressed  as  RAMP  CDIM 
specificadons.  These  files  are  inidally  created  by  using  the  Pro-engineer  feature- 
based  solid  modeling  system  with  a  form  feature-based  editor.  The  files  are  then 
translated  to  the  RAMP  CDIM  language.  Because  RAMP  CDIM  is  already 
suppordng  significant  applicadons  downstream  in  the  design,  manufacturing  and 
support  processes,  it  offers  a  valuable  source  of  data  for  NIPDE. 

2.  Second,  although  RAMP  CDIM  is  currently  supporting  downstream 
i^plicadons,  it  is  effectively  still  a  'closed  system',  rather  Aan  a  consensus  model 
produced  and  agreed  upon  by  a  wide-range  of  companies.  It  is  therefore  not 
acceptable  to  many  companies  as  a  'standard'  format  for  exchanging  form  feature 
data.  Fortunately,  there  is  a  consensus  model  for  product  data  exchange  using  the 
STEP  standard  that  is  acceptable  to  a  wide  range  of  companies,  namely  NIPDE. 
Numerous  companies  and  groups  have  agreed  to  accept  NIPDE  CDIM  product 
speciricadons  and  to  use  them  for  manufacturing  applications  that  use  form 
features.  These  applications  include  process  planning,  generative  inspection,  and 
costing.  The  companies  and  groups  that  have  agreed  to  use  NIPDE  specifications 
for  this  purpose  include:  the  National  Center  for  Manufacturing  Sciences 
(NCMS),  Pratt  &  Whimey,  Ford  Motor  Company,  Manin  Marietta,  Lawrence 
Livermore  National  Laboratory,  Cognition  Systems,  and  Techno-Soft  (a  company 
^wned  as  a  result  of  the  Air  Force  rapid  design  system  program). 

The  missing  link  between  the  first  and  second  steps  is  that  the  available  product 
data  is  expressed  early  in  the  process  in  RAMPS  CDIM  format,  whereas  the  companies 
downstream  want  the  data  to  be  expressed  in  NIPDE  CDIM  format.  Allied  Signal  has 
taken  on  the  task  of  translating  the  RAMPS  CDIM  into  the  NIPDE  CDIM  lan^age.  In 
Older  to  do  this,  they  need  an  ^vanced  reasoning  technology  that  allows  translation  rules 
to  be  easily  expres^  in  a  modular  way.  Since  Logistica  provides  this  capability.  Allied 
Sigiial  decided  to  undertake  a  project  to  write  the  necessary  translation  rules  in  the 
Logistica  language.  They  are  also  using  the  Logistica  system  to  execute  these  rules  (i.e., 
to  process  throu^  the  rules  with  data,  in  the  same  manner  as  traditional  computer 
progr^s  are  typically  executed).  Lo^stica  is  therefore  crucial  to  the  success  of  the 
machming  form  feature  translation  project,  as  every  piece  of  product  data  in  every  test 
file  will  be  manipulated  and  translate  by  the  Logistica  rule  system. 
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5  The  Ford  Project 

Allied  Signal  is  cunently  involved  in  negotiating  a  cooperative  agreement  with 
DOE  and  Ford  Motor  Company.  The  agreement  covers  a  multi-year,  multi-million  dollar 
project  to  implement  a  STEP  repository  at  Ford.  Allied  Signal  is  proposing  to  use 
Lx>gistica  on  this  pending  project  to  check  reasoning  about  Euler  constraints  to  insuring 
consistent  geometiy,  and  to  do  inference  on  product  designs. 

5.33  Longer-Term  Plans 

Together,  Logistica  and  the  nonmonotonic  rule  set  NONMON  provide  Allied 
Signal  wiA  a  unique  capability  for  reasoning  about  the  consequences  of  action,  in 
general.  The  longer-term  plans  for  use  of  Logistica  at  Allied  Signal  involve  building  a 
rule  base  for  the  domain  of  process  planning  for  manufactured  parts.  The  rule  base  will 
include  descriptions  of  various  actions,  both  planned  and  unplanned,  which  can  occur  in 
that  domain.  Using  that  rule  base,  along  with  the  generic  reasoning  rules  of  NONMON, 
Logistica  would  be  used  to  suppon  planning  and  decision-making  activities. 

6.  Conclusion 

Logistica  is  a  functional  programming  language  used  for  implementing  deductive 
reasoning  processes,  specifically  for  modeling  and  executing  the  logic  or  rules  of 
processes  or  actions  in  some  domain  of  interest.  Logistica  provides  more  generality  than 
other  languages  of  this  nature,  and  is  therefore  more  powerful  and  flexible  in  its 
application.  It  is  particularly  useful  for  cases  where  there  are  multiple  input  states  to  be 
studied,  or  where  there  are  several  alternative  processing  paths  to  be  considered. 
Logistica  is  extremely  useful  in  cases  where  the  possible  states  or  processing  paths  arc 
not  known  or  predictable  in  advance  (i.e.,  where  the  states  or  processes  are 
'indeterminate'). 

Automating  reasoning  processes  is  important  for  developing  'smart'  systems  to 
support  analysis  and  decision-making  in  complex  enterprises.  Logistica  is  intended  to  be 
us^  to  describe  the  logic  or  rules  of  domains  such  as  engineering  and  manufacturing 
operations,  as  well  as  their  supporting  management  or  business-level  processes.  Under 
this  Phase  n  SBIR,  the  Logistica  language  was  refined  and  then  operationalized  in  a 
software  tool.  The  software  was  developed  and  tested  in  a  LISP  processing  environment, 
running  on  workstations  under  the  UNIX  operating  system  and  on  Apple  Macintosh 
personal  computers.  Two  applications  of  the  technology  were  undertaken  to  establish  a 
'proof  of  principle'  of  Logistica's  capabilities. 

First,  Logistica  was  used  as  the  basis  for  designing  a  pattern-directed  invocation 
ctq)ability  for  Ontek  Corporation's  Platform  for  the  Automated  Construction  of  Intelligent 
Systems  (PACIS)  software.  This  work  was  performed  under  the  Air  Force  ManTech 
Directorate's  Integration  Toolkit  and  Methods  (ITKM)  program.  Corporate  Data 
Integration  Tools  (CDIT)  project.  Logistica  was  determined  to  be  a  quite  suitable 
technology  for  supporting  a  pattern-directed  invocation  capability.  Logistica  is  serving  as 
an  important  technological  basis  for  meeting  many  of  the  'horizontal'  technical 
requirements  of  ITKM  QDIT  —  i.e.,  fundamental  requirements  which  serve  to  support 
'vertical'  or  specialized  capabilities  in  specific  technical  areas. 

Secondly,  Logistica  and  its  associated  NONMON  rule  set  have  been  successfully 
deployed  into  a  major  manufacturing  enterprise  —  the  DOE's  Kansas  City  Plant  run  by 
AUied  Signal.  NONMON  is  a  set  of  Logistica  rules  which  implements  nonmonotonic 
reasoning  about  actions.  At  Allied  Signal,  Logistica  has  been  utilized  on  a  major  project 
involving  ti^slation  between  disparate  product  model  data  specification  formats.  Other 
uses  are  being  planned  or  proposed  include  using  Logistica  rules  as  part  of  a  STEP 


leposito^  and  as  the  basis  for  a  system  for  reasoning  about  manufacturing  actions, 
initially  in  the  domain  of  nuinufacturing  process  planning. 

In  summary,  this  SBIR  Phase  II  contract  demonstrated  the  use  of  Logistica  as  a 
solution  to  several  classes  of  real  problems  in  information  system  and  manufacturing 
environments.  Phase  III  is  intended  to  be  the  commercial  deployment  of  this  product 
either  alone  or  as  a  part  of  a  more  general  management  and  manufacturing  system. 
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